Day 01｜網站真的會被 Agent 使用嗎？我先丟了一句自然語言

安安～我是ChiYu～

今年我想拿一個很新的 Web API，做一件很老派的事：實際把它做完，再看看它到底有沒有
簡報上那麼神。

我先對 WebMCP Inspector 丟了一句很普通的需求：

幫我找台北、免費，而且適合入門者的活動。

沒有 Tool 名稱、沒有 JSON，也沒有先替 Agent 把答案圈起來。幾秒後，Inspector 的黑色
trace 裡冒出 search_events，taipei、free、beginner 也各自跑進正確欄位。

最後找到的是「WebMCP 入門工作坊」。答案本身沒有特效，活動卡片也沒有突然旋轉三圈；真正
讓我停下來看的，是答案出現以前，網站和 Agent 到底交換了什麼。

圖 1：左側是活動搜尋頁，右側保存 User prompt、Tool call、input、Tool result 與 AI result。先別只看最後回答，真正的線索都在前面。

這一幕很接近我想像中的「網站終於會說話」。但工程師看到成功畫面的習慣，通常不是立刻開
香檳，而是先問一句：真的假的？

網站原本就有表單、按鈕和 REST API，為什麼還要多一層 WebMCP？Agent 是真的理解了「搜尋
活動」，還是剛好猜中一個可以呼叫的函式？更麻煩的是，搜尋選錯頂多找不到活動；報名與取消
若也一路自動到底，事情就不只是 Demo 好不好看。

所以今天先把完成版端上桌，但不准它直接畢業。後面 29 天，我會把這張成功圖拆開，補回
人類流程、Tool contract、安全停點、部署版本與失敗紀錄。成功要留，翻車也不能掃到地毯
底下。

WebMCP 解決的是「網站怎麼說明自己會做什麼」

WebMCP 是一項仍在發展中的 Web API，也是一份
proposed web standard，目標是讓網站把功能整理成結構化 Tool，提供給瀏覽器裡的 AI Agent
使用。

我會先把它理解成：

WebMCP 是網站寫給 Agent 的能力說明書。它說清楚目前能做什麼、需要哪些輸入、會回傳
什麼，以及哪一步必須停下來交還人類。

這裡的 context 不是把整張網頁、cookie 和聊天紀錄一口氣塞進模型。以 WebMCP 的核心用途
來說，網站公開的是 Tool definition：名稱、用途、input schema、執行方式與行為提示。

各角色的責任可以先排成這樣：

網站
→ 決定哪些任務可以公開，並實作 Tool

目前 Document
→ 保存這個頁面的 Tool context

瀏覽器或 Agent Host
→ 將 Tool 提供給 Agent

Agent
→ 讀取需求、選 Tool、準備 input，再依 result 回答

沒有這層契約時，Agent 常得觀察 DOM、按鈕文字與畫面排列，再模擬點擊、輸入和捲動。這種
方式不是不能用，但它很依賴目前 UI。按鈕從「搜尋活動」改成「探索場次」，人類可能毫無
感覺，寫死文字定位的 automation 卻可能當場迷路。大後天開始，我會親手讓它迷一次。

WebMCP 沒有把畫面拿掉。人類照樣使用原本的 HTML、表單與按鈕；支援 WebMCP 的 Agent 只是
多拿到一份明確的任務契約。Chrome 的 WebMCP 說明
也把這種方向放在 progressive enhancement 裡：不支援時，網站仍然是正常網站。

Tool 名稱、Schema 與執行邏輯各管一件事

以 Imperative API 為例，一支 Tool 會包含：

名稱和 description 管的是「要不要選」，schema 管的是「參數怎麼填」，execute 才負責
「選中後做什麼」。Agent 猜錯時，這三層若混成一句「它可以搜尋」，就很難知道該修哪裡。

活動搜尋的最小契約可以讀成：

Tool name    search_events
用途         依條件搜尋公開活動
input        location、price、level、query
result       活動 ID、名稱、時間、地點與詳情網址

開頭那句自然語言，大致會走過：

使用者自然語言
→ Agent 查看目前 Document 公開的 Tool
→ 選中 search_events，依 schema 組出 input
→ 網站沿用既有 action、REST API 與 server validation
→ Tool result 回到 Agent
→ Agent 整理成最後回答

WebMCP 不會讓模型突然變成 deterministic。同一句 Prompt 仍可能因模型、context 或 Tool
組合不同而得到不同結果。它提供的是比較可控、可追查的任務入口；可靠度仍要靠 eval、trace
與失敗案例驗證。

WebMCP 不是模型、REST API 替代品，也不是權限捷徑

三個誤會可以先收掉：

• 它不是新的 AI 模型。 WebMCP 不會自己理解整個網站，選擇與回答仍由 Agent 完成。
• 它不取代 REST API。 Tool 執行時可以沿用原本的 API、action 與 server operation。
• 它不是 authorization。 Agent 選對 Tool，也不能繞過 session、CSRF、ownership 或商業規則。

原本的 client action、REST API、session 和 server validation 都還在。WebMCP 補的是任務
入口，不會因為名字很新，就順便替我們重寫商業邏輯。

實作上則有兩條主要路徑：

• Declarative API：替既有 HTML
  form 加上 toolname、tooldescription 等標註，適合搜尋與篩選。
• Imperative API：用 JavaScript
  動態註冊能力，適合 route context、結構化 result 與生命週期管理。

名字裡雖然有 MCP，也不用先多申請一台主機。WebMCP 不要求網站另外架設 MCP Server；能力
跟著目前頁面與 route 存在。MCP Server 則由 client 連線，可在頁面之外提供服務。兩者可以
一起使用，不是誰要把誰趕下班。

Tool 描述能力，真正的權限仍由 Server 把關

readOnlyHint 或 untrustedContentHint 是給 Agent 判斷的 metadata，不是安全證書。
Description 寫著「只收藏活動」，也無法保證 callback 沒有偷偷做別的事。

真正的 session、CSRF、ownership、輸入驗證、名額與截止時間，仍要由網站和 server 執行。
Chrome 的 WebMCP 安全指引 也把
Prompt Injection、敏感資料、參數驗證與高風險操作列為實作時必須面對的問題。

這就是本系列刻意採用兩支 prepare Tool 的原因：

prepare_event_registration
prepare_registration_cancellation

Agent 可以填資料、整理影響並開啟確認畫面，最後送出仍留給人類。WebMCP 可以讓 Agent 走到
門口，不能因為 Tool 名稱取得很有禮貌，就順便把門鎖拆掉。

現在適合實驗，不適合寫成所有瀏覽器都已支援

WebMCP 目前仍是 Draft Community Group Report，不是正式 W3C Standard。Chrome 的本機測試
也需要啟用 WebMCP for testing flag。

document.modelContext 位於受限制的瀏覽器能力範圍；公開環境需要 HTTPS，並要留意 origin
isolation 與 tools Permissions Policy。網站公開 Tool，也不代表任意聊天機器人都能直接
呼叫，中間仍需要支援這項能力的瀏覽器或 Agent Host。

本系列使用 Chrome、WebMCP Inspector，以及 Inspector 整合的 Gemini 測試 Agent，分別觀察：

Chrome 是否發現 Tool
Inspector 能否直接執行 Tool
Agent 能否從自然語言自行選擇與呼叫

三種畫面長得很像，證明的事情完全不同。

回到 Trace：選對 Tool 還不夠，參數也不能偷改

開頭的 Prompt 是中文，Tool input 則是：

{
  "location": "taipei",
  "level": "beginner",
  "query": "",
  "price": "free"
}

我會逐欄核對：

參數沒有偷放寬，我才繼續看 result。活動名稱、地點、費用、程度與相對詳情網址，都能在
Tool result 找到來源；最後回答沒有現場發明另一個日期或一條看起來很像真的 URL。

如果我在 Inspector 下方手動挑 search_events，再貼上 JSON，只能證明 Tool 可以執行，
不能證明 Agent 會選。這次 trace 最重要的地方，就是自然語言進來後，Agent 自行完成：

User prompt
→ Tool call
→ input
→ Tool result
→ AI result

答案讀起來越順，不代表過程越老實。少看任何一段，都可能把「剛好答對」誤認成整條鏈路
可靠。

最後完成的是五支 Tool 與三條 Journey

AgentReady Events 最後保留五個正式 Tool 名稱：

我沒有把每顆按鈕都包成 Tool。每支 Tool 要代表完整任務，說清楚輸入、結果，以及走到哪裡
必須停下來。

圖 2：首頁把五個正式名稱、三條 Journey 與人類停點放在同一張畫面。收藏可以完成，報名與取消停在確認前。

圖 2 是整個系列完成後的網站，不是今天的起始版本。今天先看終點，明天就把完成版收起來，
回到一個還沒有 WebMCP Tool 的基本網站。

這三十天會一邊實作，一邊限制自己能宣稱什麼

圖 3：先看一次完成後的使用方式，再回頭打地基。每完成一項能力就留下相應測試，不等最後才一次宣布成功。

開頭的 search_events 成功，只能證明固定版本、頁面、Prompt 與 Agent 環境中發生過一次
自然語言 invocation。它沒有順便替另外四支 Tool 通過，也不能保證換模型、Chrome profile
或日期後仍然相同。

句號先停在這裡。

回到最初那句搜尋，我們已經知道中間不只是一個 Prompt 配一個漂亮回答，還站著網站契約、
Agent 選擇、結構化 input、可追溯 result 與不能越過的人類權限。

明天先回答一個更早發生的問題：離開我的電腦後，讀者能不能把同一個網站、API、測試與
build 跑起來？